|
Is It Possible to Execute Flash Programming Algorithms from Internal SRAM but Execute Application Code from Flash? To program the external Flash connected to an E5 device, the Flash programming code must be executed from internal SRAM. The E5’s flexible code and address mappers allow you to store and execute the Flash programming algorithms in internal SRAM while the remainder of the application code remains in external Flash. However, there are many issues to consider to make this
technique possible. All of them are small and manageable by themselves, but
together become a technical project that requires complete understanding of
the E5’s memory map, code and data mappers, Flash programming, and the Keil C
complier/linker. · The Keil C compiler/linker allows you to place your code segments at a fixed location. See the Keil user manuals for detailed directions. · Choose an address for the segment containing your Flash programming functions that is well clear and separate from you other application code. · The address must begin on a large power-of-2 boundary. The power-of-2 that you select determines the maximum size for you code. If the code segment begins on a 1K-byte boundary, then the code is restricted to 1K bytes or less. Similarly, if the code segment starts on a 4K-byte boundary, then the code must be 4K bytes or less. This restriction is due to the E5’s Code mapper alignment requirements and has nothing to do with Keil. Note the start address of your Flash code, CODE_ADDRESS, and its size, SIZE. · Check the Keil listing output file, <projectname>.m51, created by the compiler to verify that the code was place where you desired. For example, if your Flash code is 4K-bytes in size and you specified 32K as the starting address for you code region, you would expect to find your Flash code starting at address 0x8000, to 0x9000.
Ensure that the processor will not jump or branch out of the code that writes to Flash until the code completely finishes the relevant Flash operation. This means that any subroutines must also be in the special Flash code segment, and all interrupt service routines (ISRs) should be disabled.
· Allocate a buffer in XDATA is at least large enough to hold the Flash code segment. · This allocated xdata buffer must also start on a XDATA that is on a boundary of SIZE. For example, if the size of your Flash code segment is 4K bytes, then specify that the XDATA buffer starts on a 4K boundary. Example: xdata char mybuffer[0x1000] _at_ 0x4000; · Place the XDATA buffer away from any other XDATA variables that may be in your application. See the Keil listing ouptut, <projectname>.m51, for a complete list of XDATA and CODE variables. Eventually this buffer will be mapped as CODE space to prevent accidental data writes to the code segment. · Copy the code from the CODE_ADDRESS to the XDATA_ADDRESS. Example: code char * mypointer = CODE_ADDRESS; xdata char mybuffer[SIZE] _at_ XDATA_ADDRESS;
for(i=0; i<SIZE ; i++) mybuffer[i]= mypointer[i]; · The physical address—not the 8052’s 16-bit logic address—f or this SRAM region will be the SRAM physical base address + XDATA_ADDRESS. The SRAM physical base address starts at 0x01_0000. This is true because the entire SRAM is dedicated to XDATA space if the program code is downloaded to and primarily executed from Flash. PHYSICAL_ADDRESS = 0x010000 + 0x4000 = 0x014000
© 2001 by Triscend Corporation. All rights reserved. |